אשמח אם תעשה אפשרות בפרופיל בנוסף ל"מה כתב" משהו בסגנון "מה ענה/הגיב" , כדי למצוא את כל התגובות של המשתמש הזה ובאיזה נושא זה נענה.
בנוגע לשאלה על האינטרפייס:
ראיתי שזה בעיקר למקרה שבו יש לך כמה מחלקות שרוצות לממש את אותה הפעולה, אבל נניח במחלקת משתמש בפונקציית ההרשמה (או מחלקת הרשמה, איך עושים את זה נכון?) , אז קודם אני יוצר את האינטרפייס המתאים, מגדיר לו כpublic את פעולת ההרשמה - וזהו. רק המחלקה הזאת תממש את הפעולה ולא מחלקה אחרת, אז למה לעשות לזה אינטרפייס?
עוד שאלה: זה בסדר לכתוב את האינטרפייס ואת הקלאס שמממש אותו באותו הקובץ? או איך עושים את זה נכון?
הדוגמה היא:
תודה רבה מראש
13 תשובות
ענה
אם אתה לא חושב שצריך interface אז אל תעשה זה אמור לעזור לך ולא להכביד עליך.במקרה של ההרשמה ,מה אם בעתיד תרצה לפתוח את ההרשמה לעוד פלטפורמות כמו אפשרות הרשמה דרך פייסבוק,גוגל וכו'? אתה תרצה שהם יממשו פונקציות מסוימות.
לרשום את ה interface איפה שהמחלקה מוגדרת זה לא נכון משום שכמה מחלקות אמורות לממש את אותו interface ולא מחלקה ספציפית
ענה
@Splash כן אתה צודק לגבי הפלטפורמות. ואם זה לא נכון אז איפה כן לרשום את הinterface? קובץ נפרד ולעשות לו require? זה תופס לגבי auto loading?
ענה
עדיף נושא אחד פר אשכול, אחרת קשה לענות על הכל. בנושא הזה אני גם אתייחס לאינטרפייס
--
באופן כללי splash עונה על כל השאלות באתר בצורה מעולה (וגם הרבה יותר מהר ממני)
אבל בעיקרון אינטרפייסים עוזרים לי בשלושה דרכים:
1. לחשוב מראש על מה כל מחלקה תעשה ואיך לפני שאני מתחיל לכתוב אותה
2. מאפשר להרחיב את המערכת בעתיד עם סוגי הזדהות אחרים כמו שsplash הראה
3. עוזר בבדיקות אוטומתיות. לא מדובר על זה באתר הרבה, אבל אני אתקן את זה :)
לגבי איפה לשים את זה:
לא יקרה שום דבר רע אם תשים את זה באותו הקובץ, אבל דווקא בשביל autoload עדיף לשים בקבצים נפרדים, בגלל ש
א. אם יש לך כמה מחלקות שממשות את אותו אינטרפייס - אתה לא תמיד צריך שגם הקוד שלהם יפוענח, בדרך כלל ממילא רק אחת מופעלת
ב. יש מוסכמה כזאת, ככה שלך יהיה יותר קל להיכנס לפרויקטים של אנשים אחרים ולהם לפרויקטים שלך כשהקבצים מופרדים אחד מהשני
אפשר הסבר לגבי המוסכמה? ז״א יש אחת לניימספייסים שזו psr-0 , מה לגבי אינטרפייסים? איך שומרים אותם נכון בדרך המקובלת?
המוסכמה היא שכל מחלקה, trait או אינטרפייס נשמרים בקובץ נפרד (לפי psr-0)
אני לא חושב שיש מוסכמה במקרה הזה (אלכס?) אבל ההיגיון אומר שה interface יהיה איפה שהמחלקות הרלוונטיות יהיו
זאת אומרת שאם יש לך נגיד -
project/class/register/Register.php
אז ה interface יהיה תחת
project/class/register/RegisterInterface
באופן כללי כל עוד זה לפי psr0 זה בסדר. המחלקה הממשת לאו דווקא חייבית להיות באותו ניימספייס (ואז גם באותם תיקיות).
למשל psr-3 מגדיר אינטרפייס סטנדרטי ללוגר והוא נראה ככה:
interface LoggerInterface {}
לאומת זאת, המחלקה המממשת יכולה להיות בניימספייס שונה לגמרי.
המוסכמה היחידית במקרה הזה היא psr0/1 ולשמור כל מחלקה/אינטרפייס/טרייט בקובץ נפרד
אוקי, הבנתי את שניכם פחות או יותר. את המחלקה להגדיר בקובץ Register.php ואת האינטרפייס בקובץ Register.interface.php , ואז לעשות require לאינטרפייס בקובץ של הקלאס, סבבה. השאלה שלי היא אם זה תופס לגבי auto loading ? כי הבנתי שהcomposer מיועד להרחבות צד שלישי (vendors) , ניתן להשתמש בזה על מחלקות שלי?
ועוד שאלה: תקני לשמור קלאסים במבנה כזה?: classname.class.php ואינטרפייס ככה? intname.interface.php ?
כן זה טופס לגבי טעינה אוטומטית.
לגבי השמות של הקבצים לא אמור להיות מצב שבו יש לך מחלקה ו interface בעלי אותו שם אחרת יהיה מאוד קשה לבצע את הטעינה [או יותר נכון-בלתי אפשרי].
תקרא ל interface עצמו במקום IRegister תקרא לו RegisterInterface ואז לא תצטרך לבצע את החיקוי קבצים הזה שסתם ידרוש ממך לכתוב עוד נתיב בטעינה אוטומטית
ענה
אני דווקא חושב שזה רעיון טוב לשים כל מה שהוא לא מחלקה עוד תיקייה פנימה - Interfaces/Register. (כנ"ל במרחבי השמות מן הסתם.)
>> תקני לשמור קלאסים במבנה כזה?: classname.class.php ואינטרפייס ככה? intname.interface.php ?
לא. זה רחוק מ psr0. היו עושים את זה ככה פעם במערכות מסוימות, אבל זה ממש לא לפי psr0 ושנית, אתה מעבד את האפשרות לבצע autoloading בצורה הזו.
אוקי הבנתי, תודה רבה חבר'ה בהחלט עזרתם לי, אגב לפי מה שהבנתי בirc שלהם הם עובדים על psr5/6, אחד מהם עוסק בcaching :)
אפשר לראות את כולם (את אלה שהתקבלו ואלו שעדיין בדיון) בריפוזיטורי שלהם fig-standards